Role - based Interface Automata ∗ Extended

Component-based software system development is based on highly specialised components, each developed to meet different objectives, which are then composed into a system with an overall objective. We propose Role-based interface automata (RI automata) [2], a new formalism for modelling and reasoning about component-based systems. We focus on the actions exposed by interfaces, and their temporal ordering because, in general, we may not have access to individual component behaviour. This formalism extends Interface Automata [1] by defining role-based actions and component objectives in a temporal action logic. A key feature of RI automata is the different types of transitions and the roles they represent. As with original interface automata, we distinguish between input for receiving, output for sending, and hidden (or internal) actions. Unlike interface automata, which conflates input with methods that can be called, and output with method calls, we further differentiate input and output actions according to three roles. These reflect fulfilment of component requirements and environment requirements, and are classified as: master, which calls (or requires), servant, which is callable (or supports, offers) and valet, which behaves like a servant or a silent (or anonymous hidden) action. Essentially a valet action is a choice that is determined by the environment. The valet does whatever is required by a master, if it can. Action names are shared between component interfaces and the role each action has in a component depends upon that component. For example, when modelling a GPS-based navigation system, the transition label i.M?loc represents the action “component i requires the loc method (get location) and receives data (for example, GPS coordinates)”. Another example is the transition label j.S!loc, which represents the action “component j offers the loc method, delivering data (e.g. GPS coordinates) to the requesting component.” The former action has a master role (M), whereas the the latter has a servant role (S). When components are composed, denoted here by ‖, they synchronise on shared actions so that input/output and role requirements are met. Informally, this means that in any composition, master actions must be synchronised with another servant or valet action (collectively known as subservient actions) in order to fulfil a component’s objectives, whereas valet and servant actions are not subject to the same constraint. Non-synchronised subservient actions represent spare capacity. Role-based interface automata interact through four types of synchronisation: MI/VO, MI/SO, MO/VI, MO/SI, where M stands for master, V for valet, S for servant, I for input and O for output. For example the action i.M?loc can synchronise with j.S!loc, as an MI/SO synchronisation. Internal actions of the component automata are interleaved asynchronously, as usual for interface automata. When composing two RI automata we use an optimistic or busy form of synchronisation. This means that if one automaton needs to perform a shared action but the other is not ready to reciprocate, we allow the first to wait until an appropriate action is offered; the latter automaton can only perform hidden actions in the meantime. If the second automaton can only follow paths in which the synchronising action is never offered, then the two automata are not compatible and the composition is not possible. RI